Re: [-empyre-] Re: semiomorphic..viral

["Nicholas F. Polys" <npolys@virtuworlds.com>]

a reference of interest to this thread:

Goguen, J. Information Visualizations and Semiotic Morphisms.  (2000) UCSD
      http://www-ecse.ucsd.edu/users/goguen/papers/sm/vzln.html

best regards,
    _n_polys

----- Original Message ----- 
From: "Jim Andrews" <jim@vispo.com>
To: "soft_skinned_space" <empyre@lists.cofa.unsw.edu.au>
Sent: Saturday, October 25, 2003 5:36 PM
Subject: RE: [-empyre-] Re: semiomorphic..viral


>
> > > Semiotic morphism was originally developed as a way to translate
> > > between different types of Graphic User Interface design. Different
> > > types of interface design can represent the same information, and this
> > > process can occur automatically via an algorithmic process - the
> > > 'content' and the representation are separated.
> > >
> > > In Semiomorph (http://iconica.org/artefact/) this idea is applied to
an
> > > electronic space which is represented as a third person digital game.
> > > All of the game elements may be represented as either text, diagrams,
> > > icons or simulation (the 'natural'  mode of game spaces - realism).
> > >
> > > Of course, it may potentially be applied to a wide range of possible
> > > systems - such as those you have described. The key element is that
the
> > > system can be described in mathematical / symbolic terms so that it
can
> > > be defined in terms of functions, variables etc.
> > >
> > > Troy
>
> In terms of Abstract Algebra, you mean? That makes sense to me. I've been
> developing a windowing/menuing set of behaviors for Shockwave (and
Director
> more generally). The elements of the algebra would be things like sprite
> channels, behaviors, and members. The operations would be things like
giving
> a sprite channel a member or a behavior. Or destroying a sprite's member
or
> behavior(s) etc.
>
> More generally (so that it isn't linked to, say, the Director
> implementation), an algebra of OOP objects.
>
> Whoever has worked with an API and done some abstract algebra may have
noted
> that manipulating the commands of an API to accomplish this or that is
very
> like doing a low-level type of abstract algebra proof where you push
symbols
> around, concatenate them, perform operations on them, in trying to prove
> some property of the system. Only in the case of mucking with the API,
> you're not trying to prove some property of the system but trying to make
> the system do a certain thing.
>
> Which is, I suppose, related to languages like Lisp which were developed
> both for artificial intelligence programming and for generating
mathematical
> proofs. More generally, languages like Lisp were developed to instantiate
> the possibility of reasoning/logic in a programming language.
>
> ja
>
> ps: here's the most intriguing isomorphism i've encountered. an
isomorphism
> between two games. first game. two players. you see the numbers 1 to 9 in
a
> row.
> 1 2 3 4 5 6 7 8 9
> the object of the game is to be the first player to select three numbers
> (not two or four) that add up to 15. So if you go first and select 5, say,
> neither you nor I can again select 5. So now it's my turn and I select 7,
> say. Then you select 6, say. Now I must choose 4 or you win. Etc.
>
> Turns out this game is isomorphic to tic tac toe
> 4 3 8
> 9 5 1
> 2 7 6
>
> Isomorphic in the sense that the two games are structurally identical. So,
> for instance, as in tic tac toe, if you play the first game well, you will
> never lose. The 'magic square' above is such that every horizontal,
> vertical, and diagonal triplet of numbers adds to 15. Moreover, all
possible
> triplets made up of numbers 1 to 9 that add to 15 are represented in the
> magic square. If this latter property did not reside in the magic square,
> the two games would not be isomorphic.
>
>
>
> _______________________________________________
> empyre forum
> empyre@lists.cofa.unsw.edu.au
> http://www.subtle.net/empyre